chore: update support handbook with community and free support #14265
Conversation
Expanded the community and free plan support documentation to clarify processes and guidelines for handling community questions and free plan tickets.
Updated guidelines for community question handling and support notifications.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
abigailbramble
requested review from
HaynesPostHog,
clr182,
corywatilo,
darkopia,
eleftheriatrivyzaki,
kyleswank,
luke-belton,
ordehi and
slshults
clr182
left a comment
clr182
left a comment
There was a problem hiding this comment.
community 2-way sync section LGTM 👍
luke-belton
left a comment
luke-belton
left a comment
There was a problem hiding this comment.
sounds great - just had a few questions/thoughts
also one other related thing that crossed my mind is - do we do anything to identify community questions from paid customers (even if just sales top 20)?
| - If you're making assumptions or suggesting approaches, be clear about that | ||
|
|
||
| **When responding in Zendesk:** | ||
| - Write your response as a public reply |
There was a problem hiding this comment.
worth adding something like this?
| - Write your response as a public reply | |
| - Check whether the user has already raised a support ticket (this should be simple in Zendesk if they sign into the community using their PostHog user email) | |
| - Write your response as a public reply |
| **How to convert:** | ||
| 1. Reply on the community thread with something like: "This needs some account-specific investigation, so I've created a support ticket for you. Check your email - we'll follow up there." | ||
| 2. Create a new ticket in Zendesk on the customer's behalf | ||
| 3. Archive the community question (this hides it from the forum listing and removes it from search indexes) |
There was a problem hiding this comment.
I'm not totally convinced by this - I could see there being cases where there could still be learnings we could share publicly on resolution?
There was a problem hiding this comment.
or e.g. 'we ultimately identified there was a bug here, here's the link to GitHub'
There was a problem hiding this comment.
Yea - I'm not totally convinced by this either. I'd seen it in the original community handbook pages. I'll update it in both.
|
|
||
| Free plan support is achieved via community questions. Free plan customers are entitled to community support and are not entitled to in-app support. | ||
|
|
||
| There are certain circumstances, however, where free plan tickets can exist within Zendesk via other means (such as through email or other channels). Free plan tickets are given the same target response time as community questions: **two weeks**. |
There was a problem hiding this comment.
should we be a bit more vague here and not say we have an email channel?
| - **Included in all support views in Zendesk** including: [Technical Support Shared View](https://posthoghelp.zendesk.com/agent/filters/32900756121627), [Billing & Accounts Support Shared View](https://posthoghelp.zendesk.com/agent/filters/38698822910875), and dedicated [Technical SME views](https://posthog.com/handbook/support/support-smes) | ||
|
|
||
| **Why two weeks?** This extended timeline serves two important purposes: | ||
| 1. It gives the community a chance to answer questions peer-to-peer before we jump in |
There was a problem hiding this comment.
if we are on top of our response time SLAs for 'paid' support, should we be running down the timers on community tickets to avoid answering too quickly and discouraging peer engagement?
| - We are building our community around our _website and content_, rather than the product itself. This is because a) PostHog is a product that you add after you have already built something, and b) 90% of community activity turns into support queries, which is not what we want community to be. | ||
|
|
||
| - We are focusing on building the community _platform_ itself - creating the tools that enable the community to interact with each other, rather than hiring a community manager whose job it is to go out and talk to everyone on other platforms/social media - this is not scalable. | ||
| - We are building our community around our _website and content_, rather than the product itself. This is because a) PostHog is a product that you add after you have already built something, and b) 90% of community activity turns into support queries, which is not what we want community to be. |
There was a problem hiding this comment.
PostHog is a product that you add after you have already built something
I don't think this is still valid - we want customers to add PostHog as early as possible so they get immediate feedback, even if their product is in early alpha/beta etc?
90% of community activity turns into support queries
maybe we just say 'the majority of'?
I know you've not added this wording, but it seems like the changes we're making aren't doing anything to address lack of engagement in the community - do we still feel the wording here best reflects our community approach?
ordehi
left a comment
ordehi
left a comment
There was a problem hiding this comment.
Would love to talk more about our approach here. Concerned we're turning the community into just another tier of the support queue. To me, this matters enough to hold up the PR. I'm happy to collaborate on building for the community. It's close to my heart, and I think it would save us a ton of boring work.
|
|
||
| - The <SmallTeam slug="content" /> doesn't 'run community' in the traditional sense, but is instead responsible for ensuring that the content hubs in particular have a steady stream of engaging content and replying to users when they engage. They also proactively respond to questions and use feedback to create new types of content such as tutorials and docs. | ||
| - The <SmallTeam slug="brand" /> builds the platform and tools. Rather than using an off-the-shelf community platform, we have rolled our own. This gives us the flexibility to do what we want with it, all without having to depend on third parties or their cookies. | ||
| - The <SmallTeam slug="content" /> doesn't 'run community' in the traditional sense, but is instead responsible for ensuring that the content hubs in particular have a steady stream of engaging content and replying to users when they engage. They also proactively respond to questions and use feedback to create new types of content such as tutorials and docs. |
There was a problem hiding this comment.
Spending more time and money on manually answering questions feels like an anti-pattern for what a community should be, we even recognize that elsewhere in this write-up. Better to invest in features that drive engagement and let the community sustain itself:
- Reputation systems: courses/quizzes that earn badges, visible "PostHog Expert" status
- Rewards for contributions: merch, discounts, public mentions for people who help others
- Commissioned content from power users: if someone's consistently helpful, invite them to write a blog post. Public shout-out for them, authentic content for us. #domoreweird
- Gamification: we've already built quests, achievements, and games into the app. Bring that energy to the community: leaderboards, embed the games directly, use them as upsell hooks. Lots of room to experiment here.
People spend hours on Reddit and HN because it entertains, educates, and opens doors. A community that's just Q&A about a specific product feels like a support channel with extra steps. Being in the community should feel like time well spent, not a chore that happens to help PostHog.
| ## Who should answer community questions? | ||
|
|
||
| **We encourage all team members to watch for new community questions, and answer them if they can.** (Questions are sent into Zendesk for the support hero, but you can help ease the burden _while_ contributing to faster response times, which can lead to more positive interactions with customers (or prospective customers). | ||
| **We encourage all team members to watch for new community questions and answer them if they can.** Questions are sent into Zendesk for the support team, but you can help ease the burden while contributing to faster response times, which can lead to more positive interactions with customers (or prospective customers). |
There was a problem hiding this comment.
This approach feels to me like it turns the community into another support channel, which isn't scalable and sidesteps the support structure we've already built. It also turns into rote work when we could be building features that actually make the community self-sustaining.
I've added a handbook page that introduces how we'll be handling community support this year 🎉
I've also attempted to update our existing community pages to align with this.
Feel free to add comments, or let me know if there's anything I've missed or not thought about.
@clr182 I'd especially like you to look this over and consider if anything is missing or if anything needs adding from the two-way sync perspective 🙏